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We present a type system to guarantee termination of TT-calculus processes that exploits input/output 
capabilities and subtyping, as originally introduced by Pierce and Sangiorgi, in order to analyse the 
usage of channels. 

We show that our system improves over previously existing proposals by accepting more pro- 
cesses as terminating. This increased expressiveness allows us to capture sensible programming 
idioms. We demonstrate how our system can be extended to handle the encoding of the simply typed 
A-calculus, and discuss questions related to type inference. 



1 Introduction 



Although many concurrent systems, such as servers, are supposed to run forever, termination is an impor- 
tant property in a concurrent setting. For instance, one would like a request to a server to be eventually 
answered; similarly, the access to a shared resource should be eventually granted. Termination can be 
useful to guarantee in turn lock- freedom properties 1 8 ] . 

In this work, we study termination in the setting of the ;r-calculus: concurrent systems are specified 

as TT-calculus processes, and we would like to avoid situations in which a process can perform an infinite 

_^ sequence of internal communication steps. Despite its conciseness, the Ti-calculus can express complex 

^ behaviours, such as reconfiguration of communication topology, and dynamic creation of channels and 

C^ threads. Guaranteeing termination is thus a nontrivial task. 

r — More specifically, we are interested in methods that provide termination guarantees statically. There 

lO exist several type-based approaches to guarantee termination in the TT-calculus ||5l[T5l[T2j|3l|4l. In these 

f~^ works, any typable process is guaranteed to be reactive, in the sense that it cannot enter an infinite 

O sequence of internal communications: it eventually terminates computation, or ends up in a state where 

I an interaction with the environment is required. 

;;• The type systems in the works mentioned above have different expressive powers. Analysing the 

• ^H expressiveness of a type system for termination amounts to studying the class of processes that are 

rS recognised as terminating. A type system for termination typically rules out some terminating terms, 

c3 because it is not able to recognise them as such (by essence, an effective type system for termination 

defines an approximation of this undecidable property). When improving expressiveness, one is inter- 
ested in making the type system more flexible: more processes should be deemed as terminating. An 
important point in doing so is also to make sure that (at least some of) the 'extra processes' make sense 
from the point of view of programming. 

Type systems for termination in the TT-calculus. Existing type systems for termination in the TT- 
calculus build on simple types [13|, whereby the type of a channel describes what kind of values it 
can carry. Two approaches, that we shall call 'level-based' and 'semantics-based', have been studied to 
guarantee termination of processes. We discuss below the first kind of methods, and return to semantics- 
based approaches towards the end of this section. Level-based methods for the termination of processes 
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originate in ||5l, and have been further analysed and developed in ^. They exploit a stratification of 
names, obtained by associating a level (given by a natural number) to each name. Levels are used to 
insure that at every reduction step of a given process, some well-founded measure defined on processes 
decreases. 

Let us illustrate the level-based approach on some examples. In this paper, we work in the asyn- 
chronous TT-calculus, and replication can occur only on input prefixes. As in previous work, adding 
features like synchrony or the sum operator to our setting does not bring any difficulty. 

According to level-based type systems, the process la{x).b{x) is well-typed provided lvl(fl:), the level 
of a, is strictly greater than \y\{b). Intuitively, this process trades messages on a (that 'cost' Ivl(fl')) for 
messages on b (that cost less). Similarly, \a{x).{b{x) \ b{x)) is also well-typed, because none of the two 
messages emitted on b will be liable to trigger messages on a ad infinitum. More generally, for a process 
of the form \a{x).P to be typable, we must check that all messages occurring in P are transmitted on 
channels whose level is strictly smaller than Ivl(a) (more accurately, we only take into account those 
outputs that do not occur under a replication in P — see Section[2]). 

This approach rules out a process like \a{x).b{x) \ \b{y).a{y) (which generates the unsatisfiable con- 
straint Ivl(a) > \v\{b) > Ivl(a)), as well as the other obviously 'dangerous' term \a{x).a{x) — note that 
neither of these processes is diverging, but they lead to infinite computations as soon as they are put in 
parallel with a message on a. 

The limitations of simple types. The starting point of this work is the observation that since existing 
level-based systems rely on simple types, they rule out processes that are harmless from the point of view 
of termination, essentially because in simple types, all names transmitted on a given channel should have 
the same type, and hence, in our setting, the same level as well. 

def _ 

If we try for instance to type the process Pq = \a{x).x{t), the constraint is Ivl(a) > \y\{x), in other 
words, the level of the names transmitted on a must be smaller than a's level. It should therefore be licit 
to put Pq in parallel with a{p) \a{q), provided Ivl(p) < lvl(fl;) and Ivl(^) < lvl(fl:). Existing type systems 
enforce that p and q have the same type for this process to be typable: as soon as two names are sent on 
the same channel (here, a), their types are unified. This means that if for some reason (for instance, if 
the subterm \p{z.).q{z) occurs in parallel) we must have \y\{p) > Ivl(g), the resulting process is rejected, 
although it is terminating. 

We would like to provide more flexibility in the handling of the level of names, by relaxing the con- 
straint that p and q from the example above should have the same type. To do this while preserving 
soundness of the type system, it is necessary to take into account the way names are used in the contin- 
uation of a replicated input. In process Pq above, x is used in output in the continuation, which allows 
one to send on a any name (of the appropriate simple type) of level strictly smaller than Ivl(a). If, on the 

def 

Other hand, we consider process Pi = \b{y).\y{z)-c{z), then typability of the subterm \y(z).c{z) imposes 
Ivl(j) > Ivl(c), which means that any name of level strictly greater than Ivl(c) can be sent on b. In this 
case. Pi uses the name y that is received along b in input. We can remark that divergent behaviours would 
arise if we allowed the reception of names having a bigger (resp. smaller) level in Pq (resp. Pi). 

Contributions of this work. These observations lead us to introduce a new type system for termination 
of mobile processes based on Pierce and Sangiorgi's system for input/output types (i/o-types) [1 1 j. I/o- 
types are based on the notion of capability associated to a channel name, which makes it possible to 
grant only the possibility of emitting (the output capability) or receiving (the input capability) on a given 
channel. A subtyping relation is introduced to express the fact that a channel for which both capabilities 
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are available can be coerced to a channel where only one is used. Intuitively, being able to have a more 
precise description of how a name will be used can help in asserting termination of a process: in Pq, only 
the output capability on x is used, which makes it possible to send a name of smaller level on a; in Pi, 
symmetrically, y can have a bigger level than expected, as only the input capability on y is transmitted. 

The overall setting of this work is presented in Section [2j together with the definition of our type 
system. This system is strictly more expressive than previously existing level-based systems. We show 
in particular that our approach yields a form of 'level polymorphism', which can be interesting in terms 
of programming, by making it possible to send several requests to a given server (represented as a process 
of the form \f{x).P, which corresponds to the typical idiom for functions or servers in the Ti-calculus) 
with arguments that must have different levels, because of existing dependencies between them. 

In order to study more precisely the possibility to handle terminating functions (or servers) in our 
setting, we analyse an encoding of the A-calculus in the Ti-calculus. We have presented in [3] a coun- 
terexample showing that existing level-based approaches are not able to recognise as terminating the 
image of the simply-typed A -calculus (STA) in the Ti-calculus (all processes computed using such an 
encoding terminate fT3l). We show that this counterexample is typable in our system, but we exhibit 
a new counterexample, which is not. This shows that despite the increased expressiveness, level-based 
methods for the termination of TT-calculus processes fail to capture terminating sequential computation 
as expressed in STA. 

To accommodate functional computation, we exploit the work presented in Pl, where an impure 
TT-calculus is studied. Impure means here that one distinguishes between two kinds of names. On one 
hand, functional names are subject to a certain discipline in their usage, which intuitively arises from the 
way names are used in the encoding of STA in the Ti-calculus. On the other hand, imperative names do 
not obey such conditions, and are called so because they may lead to forms of stateful computation (for 
instance, an input on a certain name is available at some point, but not later, or it is always available, but 
leads to different computations at different points in the execution). 

In m, termination is guaranteed in an impure Ti-calculus by using a level-based approach for impera- 
tive names, while functional names are dealt with separately, using a semantics-based approach i TTSlfTlt . 
We show that that type system, which combines both approaches for termination in the ;r-calculus, can 
be revisited in our setting. We also demonstrate that the resulting system improves in terms of expres- 
siveness over H, from several points of view. 

Several technical aspects in the definition of our type systems are new with respect to previous works. 
First of all, while the works we rely on for termination adopt a presentation a la Church, where every 
name has a given type a priori, we define our systems a la Curry, in order to follow the approach for 
i/o-types in ||TT|. As we discuss below, this has some consequences on the soundness proof of our 
systems. Another difference is in the presentation of the impure calculus: iH uses a specific syntactical 
construction, called def , and akin to a let . . in construct, to handle functional names. By a refinement 
of i/o-types, we are able instead to enforce the discipline of functional names without resorting to a 
particular syntactical construct, which allows us to keep a uniform syntax. 

We finally discuss type inference, by focusing on the case of the localised n-calculus (Ltt). Ltt 
corresponds to a certain restriction on i/o-types. This restriction is commonly adopted in implementations 
of the TT-calculus. We describe a sound and complete type inference procedure for our level-based system 
in Ltt. We also provide some remarks about inference for i/o-types in the general case. 

Paper outline. Section [2]presents our type system, and shows that it guarantees termination. We study 
its expressiveness in Section [3] Section |4] discusses type inference, and we give concluding remarks in 
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Section [5] For lack of space, several proofs are omitted from this version of the paper. 

2 A Type System for Termination with Subtyping 

2.1 Definition of the Type System 

Processes and types. We work with an infinite set of names, ranged over using a,b,c,...,x,y, 

Processes, ranged over using P, Q,R, . . . , are defined by the following grammar (• is a constant, and we 
use V for values): 

P ::= 0\Pi\P2\a{v) \{va)P\a{x).P\\a{x).P v ::= *\a. 

The constructs of restriction and (possibly replicated) input are binding, and give rise to the usual 
notion of a-conversion. We write fn{P) for the set of free names of process P, and P[b/x] stands for the 
process obtained by applying the capture-avoiding substitution of x with b in P. 

We moreover implicitly assume, in the remainder of the paper, that all the processes we manipulate 
are written in such a way that all bound names are pairwise distinct and are different from the free names. 
This may in particular involve some implicit renaming of processes when a reduction is performed. 

The grammar of types is given by: 

T ::= fT \ \''T | o^^r | U , 

where A; is a natural number that we call a level, and U stands for the unit type having * as only value. 
A name having type jj*^r has level k, and can be used to send or receive values of type T, while type \^T 
(resp. o'^T) corresponds to having only the input (resp. output) capability. 

Figure [T] introduces the subtyping and typing relations. We note < both for the subtyping relation 
and for the inequality between levels, as no ambiguity is possible. We can remark that the input (resp. 
output) capability is covariant (resp. contravariant) w.r.t. <, but that the opposite holds for levels: input 
requires the supertype to have a smaller level. 

r ranges over typing environments, which are partial maps from names to types - we write r(a) = T 
if r maps a to T. dom(r), the domain of F, is the set of names for which F is defined, and F, a : T stands 
for the typing environment obtained by extending F with the mapping from atoT, this operation being 
defined only when a ^ dom(F). 

The typing judgement for processes is of the form F \- P .w, where w is a natural number called the 
weight of P. The weight corresponds to an upper bound on the maximum level of a channel that is used 
in output in P, without this output occurring under a replication. This can be read from the typing rule 
for output messages (notice that in the first premise, we require the output capability on a, which may 
involve the use of subtyping) and for parallel composition. As can be seen by the corresponding rules, 
non replicated input prefix and restriction do not change the weight of a process. The weight is controlled 
in the rule for replicated inputs, where we require that the level of the name used in input is strictly bigger 
than the weight of the continuation process. We can also observe that working in a synchronous calculus 
would involve a minor change: typing a synchronous output a{v) .P would be done essentially like typing 
a{v) I P in our setting (with no major modification in the correctness proof for our type system). 

As an abbreviation, we shall omit the content of messages in prefixes, and write a and a for a{x) and 
a{-k) respectively, when a's type indicates that a is used to transmit values of type U. 
Example 1 The process \a{x) .x{t) \ a{p) \ a{q) \ \p{z) .q{z)from SectionU\can be typed in our type system: 
we can set a : jf'o T,p : '^T,q : o^T. Subtyping on levels is at work in order to typecheck the subterm 



a{q). We provide a more complex term, which can be typed using similar ideas, in Example 15 below. 
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Subtyping < is the least relation that is reflexive, transitive, and satisfies the following rules: 

T <S h<k2 T <S ki<k2 

fT<\''T fT<o^T i*2r< 1*^15 o^'S<o''-T 

Typing values 

r(a) = T Fh a:T T <U 

rh *:U Fh a:T Fh a:U 

Typing processes 

r h a : o^r r h V : r r h a : i^r F,x:T h P:w 



r 1-0:0 Fha{v):k Fha{x).P:w 

Fha:\''T F,x:ThP:w k>w F,a:ThP:w T h Pi : wi T h P2 : ^2 

rh!a(x).P:0 Fh{Va)P:w T h Pi|P2 : max(wi,>V2) 

Figure 1: Typing and Subtyping Rules 



a{x).P I a{v) — > P[v/x] \a{x).P \ a{v) — > \a{x).P \ P[v/x] 

P — >P' P — >P' Q = P P — >P' P' = Q' 



P\Q^P'\Q iVa)P^{Va)P' Q^Q' 

Figure 2: Reduction of Processes 

Reduction and termination. The definition of the operational semantics relies on a relation of struc- 
tural congruence, noted =, which is the smallest equivalence relation that is a congruence, contains 
a-conversion, and satisfies the following axioms: 

P\iQ\R) = {P\Q)\R P\Q = Q\P P|0 = P 

(Va)0 = {Va){vb)P = {vb){Va)P {Va){P\Q) = P\{Va)Qii a ^fn{P) 

Note in particular that there is no structural congruence law for replication. 
Reduction, written — >, is defined by the rules of Figure |2] 

Definition 2 (Termination) A process P diverges if there exists an infinite sequence of processes {Pi)i>o 
such that P = Po and for any i, Pi — > Pi+\- P terminates (or P is terminating) ifP does not diverge. 

2.2 Properties of the Type System 

We first state some (mostly standard) technical properties satisfied by our system. 
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Lemma 3 IfF h P : w and w / then for any w' >w,T \- P :w' . 

Proposition 4 (Narrowing) IfY,x:T\-P:w and T' < T, then Y ,x : T' ^ P : w' for some w' < w. 

Lemma 5 IfP = Q, then T 'r P -.w iffT "r Q:w. 

Lemma 6 lfT,x : T h P : w, T h b : T' and T' <T then Y h P[b/x] : w', for some w' < w. 

Proof (sketch). This is a consequence of Lemma|4| as we replace xby a name of smaller type. 

Theorem 7 (Subject reduction) Ifr\-P:w and P — > P', then F \- P' : w' for some w' < w. 

Proof (sketch). By induction over the derivation ofP — > P'. The most interesting case corresponds to 
thecase where P = \a{x).Pi \ d{v) — > P' =\a{x).Pi \ Pi[v/x]. BytypabilityofP, wehaveF h \a{x).Pi :0. 
Let Ta = r{a). Typability ofP gives r,x :T \- P\ :wi for some T and w\ such that Ta < '\^T and w\ < 
k < Ivl(a). Typability ofa{v) gives Ta < o'^ U for some k' > Ivl(a), with w = k' and F \- v -.U. The two 
constraints on Ta entail T <U, and hence, byLemma^ T h A[v/;c] : W2 for some W2 <w\ < \\/\{a) < k' . 
We then conclude Y ^ P' : W2. 

Termination. Soundness of our type system, that is, that every typable process terminates, is proved 
by defining a measure on processes that decreases at each reduction step. A typing judgement T \- P .w 
yields the weight w of process P, but this notion is not sufficient (for instance, a | a | a — > a, and the 
weight is preserved). We instead adapt the approach of |1|, and define the measure as a multiset of 
natural numbers. This is done by induction over the derivation of a typing judgement for the process. 
We will use & to range over typing derivations, and write ^ : F h P : w to mean that i^ is a derivation 
of r h P : w. 

To deduce termination, we rely on the multiset extension of the well-founded order on natural num- 
bers, that we write >mui- ^2 >miti Mi holds if Mi =N^Ni, M2 =N^N2, A'^ being the maximal such 
multiset (tt) is multiset union), and for all ei G A'^i there is e2 G N2 such that ei < ^2- The relation >„,„/ is 
well-founded. We write Mi >„„,/ M2 if Mi >,„„/ M2 or Mi = M2. 

Definition 8 Suppose Si '.T \- P :w. We define a multiset of natural numbers, noted ^{S)\ by induction 
over S as follows: 

IfS : r h then J^{S) = //^ : T h a{b) : k then J^{Q)) = {lvl{a)) 

lfQ}:TV- \a{x).P : then ^{&) = 

//^ : r h aix).P : w, then ^{&) = ^(^1), where &i:r,x:T h P:w 

lf& : r h {va)P : w, then .£{Si) = J^{&i), where ^1 : r,a : P h P : w 

lf& : r h P1IP2 : max(wi,W2), then Jl{3)) = J{{'3Ji)^J{{3)2), where %:T^ Pi, / = 1,2 

Given F and P, we define ^y{P), the measure ofP with respect to T, as follows: 

Ji^r{P) = min(^(^), ^ : T h P : w for some w) . 

Note that in the case of output in the above definition, we refer to Ivl(a), which is the level of a 
according to F (that is, without using subtyping). We have that if F h P : w, then V^ G ^r{P),k < w. 
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Lemma 9 Suppose T h P : w, r(x) = T, r(v) = T' and T' < T. Then ^y{P) >mui ^r{P[v/x]). 
Proof Follows from Lemma ^ and by definition of ^y ( • ) ■ ^ 

Lemma 10 IfV h P : w and P=Q, then F h 2 : w' for some w' and ^y{P) = -^t{Q)- 

We are now able to derive the essential property of ^r(')" 
Lemma 11 IfY^ P:w and P — > P', then ^y{P) >mui ^t{P')- 
Theorem 12 (Soundness) IfY \- P -.w, then P terminates. 

Proof Suppose that P diverges, i.e., there is an infinite sequence{Pi)j^f^, where Pi — > Pi+i, P = Pq. 
According to Theorem^every Pj is typable. Using Lenmia 11 wehave^Y{Pi) >mui -^r{Pi+\) for alii, 



which yields a contradiction. D 

Remark 13 (a la Curry vs a la Church) Our system is presented a la Curry. Existing systems for ter- 
mination ^^ are a la Church, while the usual presentations ofi/o-types / [77]/ are a la Curry. The latter 
style of presentation is better suited to address type inference (see Section [?]). This has however some 
technical consequences in our proofs. Most importantly, the measure on processes (Definition |S]) would 
be simpler when working a la Church, because we could avoid to consider all possible derivations of a 
given judgement. We are not aware of Church- style presentations of i/o-types. 

3 Expressiveness of our Type System 

For the purpose of the discussions in this section, we work in a polyadic calculus. The extension of our 
type system to handle polyadicity is rather standard, and brings no particular difficulty. 

3.1 A More Flexible Handling of Levels 

Our system is strictly more expressive than the original one by Deng and Sangiorgi fS\, as expressed by 
the two following observations (Lemma 14 and Example [T5]): 



Lemma 14 Any process typable according to the first type system of [y5J is typable in our system. 

Proof The presentation of ^ differs slightly from ours. The first system presented in that paper can be 
recast in our setting by working with the # capability only (thus disallowing subtyping), and requiring 
type ti*^r for a in the first premise of the rules for output, finite input and replicated input. We write 
r ho P -w for the resulting judgement. We establish that F ho P : w implies F \- P :w by induction 
over the derivation of F ho P : w. D 

We now present an example showing that the flexibility brought by subtyping can be useful to ease 
programming. We view replicated processes as servers, or functions. Our example shows that it is 
possible in our system to invoke a server by passing names having different levels, provided some form 
of coherence (as expressed by the subtyping relation) is guaranteed. This form of "polymorphism on 
levels" is not available in previous type systems for termination in the Ti-calculus. 

Example 15 (Level-polymorphism) Consider the following definitions (in addition to polyadicity, we 
accommodate the first-order type of natural numbers, with corresponding primitive operations): 

Fi = \fi{n,r).f{n*n) 

Fi = \f2{m,r).{vs){7,{m+\,s)\s{x).r{x+l)) 
Q = ^■g{p,x,r).{Vs)((p{x,s)\s{y).p{y,r)) 
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Fi is a server, running at fi, that returns the square of a integer on a continuation channel r (which is its 
second argument). F2 is a server that computes similarly (m + 1 ) + 1, by making a call to F\ to compute 
[m + 1)^. Both F\ and F2 can be viewed as implementations of functions of type int -> int. 

Q is a "higher-order server": its first argument p is the address of a server acting as a function of 
type int -> int, and Q returns the result of calling twice the function located at p on its argument 
(process Q thus somehow acts like Church numeral 2). 

Let us now examine how we can typecheck the process 

Fi |F2|eU(/i,4,fi)U(/2,5,f2) . 

F2 contains a call to f\ under a replicated input on /2, which forces lvl(/2) > lvl(/i). In the type systems 
of /l5]/, this prevents us from typing the processes above, since f\ and /2 should have the same type 
(and hence in particular the same level), both being used as argument in the outputs on g. We can 
type this process in our setting, thanks to subtyping, for instance by assigning the following types: g : 

o^^{o''^T,U,V)j2 : t'T, /i : f T, with ki < ^2. 

It can be shown that this example cannot be typed using any of the systems of |l5l. It can however 
be phrased (and hence recognised as terminating) in the "purely functional TT-calculus" of f?], that is, 
using a semantics-based approach — see also Section [33] It should however not be difficult to present a 
variation on it that forces one to rely on levels-based type systems. 

3.2 Encoding the Simply-Typed A -calculus 

We now push further the investigation of the ability to analyse terminating functional behaviour in the 
TT-calculus using our type system, and study an encoding of the A -calculus in the TT-calculus. 

We focus on the following parallel call-by-value encoding, but we believe that the analogue of the 
results we present here also holds for other encodings. A A-term M is encoded as [[M]]p, where p is a. 
name which acts as a parameter in the encoding. The encoding is defined as follows: 

[[Ax.M]], '1/ (vy) {\y{x,q).m,\p(j)) [[x]], '^^ p{x) 

[[MN}/^' {yq,r) [im, \ [[Nl \ q{f).r{z)-f{z,p)) 
We can make the following remarks: 



• 



• 



A simply-typed A-term is encoded into a simply-typed process (see 1131 ). Typability for termina- 
tion comes into play in the translation of A-abstractions. 

The target of this encoding is Ln, the localised n-calculus in which only the output capability is 
transmitted (see also SectionW.lb. 



O provides a counterexample to typability of this encoding for the first type system of Q (the proof 
of this result also entails that typability according to the other, more expressive, type systems due to Deng 
and Sangiorgi also fails to hold). Let us analyse this example: 

Example 16 (From |I3||) The X-term M\ = f (Ax.(/ u {u v)) can be typed in the simply typed A- 
calculus, in a typing context containing the hypotheses f : (a — > t) — > T — > T,v : (j,u : <j — > T. 



[[Ajc. (/ u {u v) 
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Computing [[Mi]]p yields the process. ■ 

(V^,r) 

(vy) ( r{y) 

I Hx,q').{Vqi,ri,q2,r2,q3,r3) 

( ^lif) I Mi^) I qi{f2)-r2{Z2)-f2{Z2,qi) Ifuic, 

I ^3(«) I ''3(v) I q3{f3).r3{Z3)-f3{z3,r[) [[m v]],i 

I ^i(/i).ri(zi).7i(zi,^') )) 
I W) I 9(/).r(z)./(z,p) 
Tjfwe try and type this term using the first type system of [5^, we can reason as follows: 

1. By looking at the line corresponding to [[/ m]]^;, we deduce that the types of f and fj are unified, 
and similarly for zi '^nd u. 

2. Similarly, the next line f [[m v%J implies that the types 0//3 and u are unified. 

3. The last line above entails that the types assigned to f and f must be unified, and the same for the 
types ofz andy (because of the output f(y)). 

If we write ^^{Ti,T2) for the type (simple) assigned to f, we have by remarklljthat u has type T\, 
and the same holds for y by remark^ In order to typecheck the replicated term, we must have Ivl(j) > 
lvl(/3) = IvI(m) by remark^ which is impossible since y and u have the same type. 

While [[Mi]]p cannot be typed using the approach of [5], it can be using the system of SectionHj 
Indeed, in that setting y and u need not have the same levels, so that we can satisfy the constraint 
\y\{y) > IvI(m). The last line above generates an output f{y,p), which can be typed directly, without use 
of subtyping. To typecheck the output f{u,qi), we "promote" the level of u to the level of y thanks to 
subtyping, which is possible because only the output capability on u is transmitted along f. 

It however appears that our system is not able to typecheck the image of STA, as the following (new) 
counterexample shows: 
Example 17 We first look at the following rather simple K-calculus process: 

{Vu)[\u{x).x\ (vv)(!v.m(?) \u{v))) . 

This process is not typable in our type system, although it terminates. Indeed, we can assign a type of 
the form [j*o"I[J to u, and [|'"U to v. Type-checking the subterm \v.u.{t) imposes k <m, and type-checking 
\u{x).x imposes k> n. Finally, type-checking u{v) gives m<n, which leads to an inconsistency. 
We can somehow 'expand' this process into the encoding of a X-term: consider indeed 

M2 =' {?iu.{{?iv.{uv)){?iy{ut)))) {Xx.{xa)) . 

We do not present the (rather complex) process corresponding to [[M2]]p. We instead remark that there is 
a sequence of reductions starting from [[^2]]^ and leading to 

\yi{u,q\).{\y3{v,qA).u{v,qA)\\y5{y,q5)-u{t,qs)\y3{y5,q\)) \ \y2{x,q2)-x{a,q2) \ yi{y2,p) • 

These first reduction steps correspond to 'administrative reductions' (which have no counterpart in the 
original X -calculus term). We can now perform some communications that correspond to ^-reductions, 
and obtain a process which contains a subterm of the form 

u(v,/7) I \y{y,q=,).u{i,q5) \ \u{x,q2).x{a,q2) . 

Some channel names appear in boldface in order to stress the similarity with the process seen above: for 
the same reasons, this term cannot be typed. By subject reduction (Theorem^, a typable term can only 
reduce to a typable term. This allows us to conclude that [[^2]]^ is not typable in our system. 
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r,x:T»-h P:w k>w TJ:o^T^a:o"U T J : o'^T 'r v. U 

r»f:o''Thlf{x).P:0 F • f : o'^T h a{v) : n 

rhc:i"r r,x:T,f:o''U»-hP:w n>w 
r»f:o''Uh c{x).P:0 

rhc:\"T r,x:T,f:o^U»-hP:w n>w r./:o^ThPi T • / : o'^r h P2 



r»f:o''Uhlc{x).P:0 F • f : o'^T h Pi\P2 

r,g -.o^T •f:o"U "r P:w r,c : fT • f : o'^U h P :w 

r»g:o''T h {vf)P:w F • f : o'^U h {Vc)P -.w 

Figure 3: Typing Rules for an Impure Calculus 



3.3 Subtyping and Functional Names 

In order to handle functional computation as expressed by STA, we extend the system of Section|2] along 
the lines of H. The idea is to classify names into functional and imperative names. Intuitively, functional 
names arise through the encoding of STA . For termination, these are dealt with using an appropriate 
method — the 'semantics-based' approaches discussed in Section [TJ and introduced in (T5[ [T2L For 
imperative names, we resort to (an adaptation of) the rules of Section [2] 

Our type system is a la Curry, and the kind of a name, functional or imperative, is fixed along the 
construction of a typing derivation. Typing environments are of the form F • f : d^T — the intuition is 
that we isolate a particular name, /. / is the name which can be used to build replicated inputs where / 
is treated as a functional name. The typing rules are given on Figure |3] There are two rules to typecheck 
a restricted process, according to whether we want to treat the restricted name as functional (in which 
case the isolated name changes) or imperative (in which case the typing hypothesis is added to the F part 
of the typing environment). 

The typing rules of Figure [3] rely on i/o-capabilities and the isolated name to enforce the usage 
of functional names as expressed in |[T2l . In lH, a specific syntactical construct is instead used: we 
manipulate processes of the form def / = {x)P\ in Pj (that can be read as (v/) {\f{x).P\ \ P2)), where 
/ does not occur in Pi and occurs in output position only in P2. 

Let us analyse how our system imposes these constraints. In the rule for restriction on a functional 
name, the name g, that occurs in 'isolated position' in the conclusion of the rule, is added in the 'non 
isolated' part of the typing environment in the premise, with a type allowing one to use it in output only. 

In the rules for input on an imperative name (replicated or not), the typing environment is of the 
form r • — in the premise where we typecheck the continuation process: this has to be understood as 
F • d : o^r, for some dummy name d that is not used in the process being typed. We write ' — 'to stress 
the fact that we disallow the construction of replicated inputs on functional names. The functional name 
/ appears in the aforementioned premise in the 'non isolated' part of the typing environment, with only 
the output rights on it. Forbidding the creation of replicated inputs on functional names under input 
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prefixes is necessary because of diverging terms like the following (c is imperative, / is functional): 

c{x).\f{y).x{y) \c{f)\f{v) . 

Note also that typing non replicated inputs (on imperative names) involves the same constraints as 
for replicated inputs, like in [4|: the relaxed control over functional names requires indeed to be more 
restrictive on all usages of imperative names. 

The notation F • — is also used in the rule to type a replicated input on a functional name, and we 
can notice that in this case / cannot be used at all in the premise, to avoid recursion. 

In addition to the gain in expressiveness brought by subtyping, we can make the following remark: 

Remark 18 (Expressiveness) As in /¥"/, our system allows one to typecheck the encoding of a STX term, 
by treating all names as functional, and assigning them level 0. 

Moreover, our type system makes it possible to typecheck processes where several replicated inputs 
on the same functional name coexist, provided they occur 'at the same level' in the term. For instance, a 
term of the form (v/) {\f{x).P \ \f{y).Q \ R) can be well-typed with f acting as afunctional name. This 
is not possible using the def construct of [4]. 

Another form of expressiveness brought by our system is given by typability of the following process: 
\u{x).x I \v.M{t) I u{v) I c{y).Tl{c). Here, name c must be imperative while name v must be functional, 
and both are emitted on u. This is impossible in |j4|, where every channel carries either a functional or 
an imperative name. In our setting, only the output capability on c is transmitted along u, so in a sense c 
is transmitted 'as a functional name'. 

Because of the particular handling of restrictions on functional names, the analogue of Lemma [5] 
does not hold for this type system: typability is not preserved by structural congruence. Accordingly, the 
subject reduction property is stated in the following way: 

Theorem 19 (Subject reduction) IfT • / : o^T \- P -.w and P — > P', then there exist Q and w' <w s.t. 
P' = QandT» f:o^T ^ Q: w'. 

Theorem 20 (Soundness) IfT»f:o^T\-P:w, then P terminates. 

Proof (sketch). The proof has the same structure as the corresponding proof in [4]. An important aspect 
of that proof is that we exploit the termination property for the calculus where all names are functional 
without looking into it. To handle the imperative part, we must adapt the proof along the lines of the 



termination argument for Theorem 12 



4 Type Inference 

We now study type inference, that is, given a process P, the existence of F, w such that F \- P -.w. There 
might a priori be several such F (and several w: see Lemma[3]l. Type inference for level-based systems 
has been studied in |T|, in absence of i/o-types. We first present a type inference procedure in a special 
case of our type system, and then discuss this question in the general case. 

4.1 Type Inference for Termination in the Localised ;r-calculus 

In this section, we concentrate on the localised n-calculus, Ln, which is defined by imposing that chan- 
nels transmit only the output capability on names: a process like a{x).x{y).0 does not belong to Ltt, as it 
makes use of the input capability on x. From the point of view of implementations, the restriction to Ln 
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makes sense. For instance, the language JoCaml fTOl implements a variant of the TT-calculus that follows 
this approach: one can only use a received name in output. Similarly, the communication primitives in 
Erlang [9,| can also be viewed as obeying to the discipline of Ln: asynchronous messages can be sent 
to a PiD (process id), and one cannot create dynamically a receiving agent at that PiD: the code for the 
receiver starts running as soon as the PiD is allocated. 

Technically, Ltt is introduced by allowing the transmission of o-types only. We write F \-^^ P : w 
if F h P : w can be derived in such a way that in the derivation, whenever a type of the form T]*T]'* T 
occurs, we have X]' = o (types of the form \'^T and ^'^T appear only when typechecking input prefixes 
and restrictions). Obviously, typability for \-^''^ entails typability for h , hence termination. It can also be 
remarked that in restricting to Ltt, we keep an important aspect of the flexibility brought by our system. 
In particular, the examples we have discussed in Section [3] — Example [15} and the encoding of the 
A-calculus — belong to Ltt. 

We now describe a type inference procedure for h^''^ . For lack of space, we do not provide all details 
and proofs. 

We first check typability when levels are not taken into account. For this, we rely on a type inference 
algorithm for simple types [14], together with a simple syntactical check to verify that no received name 
is used in input. When this first step succeeds, we replace ftT types with oT types appropriately in the 
outcome of the procedure for simple types (a type variable may be assigned to some names, as, e.g., to 
name x in process a{x).b{x)). 

What remains to be done is to find out whether types can be decorated with levels in order to ensure 
termination. As mentioned above, we suppose w.l.o.g. that we have a term P in which all bound names 
are pairwise distinct, and distinct from all free names. We define the following sets of names: 

• names(P) stands for the set of all names, free and bound, of P; 

• bn(P) is the set of names that appear bound (either by restriction or by input) in P; 

• rcv(P) is the set of names that are bound by an input prefix in P (;c G rcv(P) iff P has a subterm of 
the form a{x).Q or \a{x).Q for some a,Q); 

• res(P) stands for the set of names that are restricted in P (a G res(P) iff P has a subterm of the 
form {va)Q for some Q). 

We have bn(P) = rcv(P) tt)res(P) (where l±) stands for disjoint union), and names(P) = bn(P) l±)fn(P). 
Moreover, for any x £ rcv(P), there exists a unique a G fn(P) Ures(P) such that P contains the prefix 
a{x) or the prefix \a{x): we write in this case a = father(x) (a G fn(P) Ures(P), because we are in Ltt). 
We build a graph as follows: 

• For every name n G fn(P) Ures(P), create a node labelled by n, and create a node labelled by 
son(/i). Intuitively, if n has type ^'^S of 0^5, son(«) has type S. In case type inference for simple 
types returns a type of the form a, where a is a type variable, for n, we just create the node n. 

• For every x G rcv(P), let a = father(x), add x as a label to son(a). 

Example 21 We associate to the process P = a{x).{vb)x{b) \ \a(y).{c{y) \ d{z).y{z)) the following set 
of 8 nodes with their labels: {a} , {son(a) ,x,y},{b}, {son(Z7) } , {c} , {son(c) ,y},{d}, {son{d) , z}. 

The next step is to insert edges in our graph, to represent the constraints between levels. 

• For every output of the form n{m), we insert an edge labelled with ">" from son(?i) to m. 

• For every subterm of P of the form \a{x).Q, and for every output of the form h{m) that occurs in 
Q without occurring under a replication in Q, we insert an edge a —^n. 
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Example 22 The graph associated to process \c{z)-b{z) \d{c) \a{b) has nodes 

{a},{&on{a)},{b},{son{b)},{c},{son{c),z} , 
and can be depicted as follows: a 




son(a) son{b) ^{son(c),z} 

The last phase of the type inference procedure consists in looking for an assignment of levels on the 
graph: this is possible as long as there are no cycles involving at least one — ;• edge in the graph. 

At the beginning, all nodes of the graph are unlabelled; we shall label them using natural numbers. 

1 . We go through all nodes of the graph, and collect those that have no outgoing edge leading to an 
unlabelled node in a set y. 

2. If y is not empty, we label every node nin y as follows: we start by setting n's label to 0. 

We then examine all outgoing edges of n. For every n ^> m, we replace n's label, say k, with 
max(/c,^'), where k' is m's label, and similarly for n —^m edges, with max(/:,^' + 1)- 
We then empty y, and start again at step[T] 

3. If y = 0, then either all nodes of the graph are labelled, in which case the procedure terminates, 
or the graph contains at least one oriented cycle. If this cycle contains at least one — ;■ edge, the 
procedure stops and reports failure. Otherwise, the cycle involves only ^> edges: we compute the 
level of each node of the cycle along the lines of step |2] (not taking into account nodes of the cycle 
among outgoing edges), and then assign the maximum of these labels to all nodes in the cycle. We 
start again at step [T] 

This procedure terminates, since each time we go back to step[TJ strictly more nodes are labelled. 



Example 23 On the graph of Example 22 the procedure first assigns level to nodes a, b and {son{c),z}- 
In the second iteration, y = {son(Zj),c}; level is assigned to son[b), and 1 to c. Finally, level 1 is 
assigned to son(a). This yields the typing b : o*'o*'r,c : ]\^o^T,a : o^o^o^T for the process of Example 22 



As announced above, for lack of space we have described only the main steps of our type inference 
procedure. Establishing that the latter has the desired properties involves the introduction of an auxiliary 
typing judgement (that characterises \-^'^), and explaining how types are reconstructed at the end of the 
procedure. This finally leads to the following result: 

Theorem 24 There is a type inference procedure that given a process P, returns F, w s.t. F h^"' P :w iff 
there exists r,w' s.t. V h^'^ P : w'. 

4.2 Discussion: Inferring i/o- Types 

If we consider type inference for the whole system of Section |2} the situation is more complex. We start 
by discussing type inference without taking the levels into account. If a process is typable using simple 
types (that is, with only types of the form jjr), one is interested in providing a more informative typing 
derivation, where input and output capabilities are used. 

For instance, the process a{x).x{t) can be typed using different assignments for a: '\oT, flor, ifjr, 
and tlttr — if we suppose t : T. Among these, ioT is the most informative (intuitively, types featuring 
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'less #' seem preferable because they are more precise). Moreover, it is a supertype of all other types, 
thus acting as a 'candidate' if we were to look for a notion of principal typing. Actually, in order to 
infer i/o-types, one must be able to compute lubs and gibs of types, using equations like glb{\T,\U) = 
\glb{T,U), glb{\T,oU) = ftglb{T,U), and glb{oT,oU) = olub{T,U). The contravariance of o suggests 
the introduction of an additional capability, that we shall note t, which builds a supertype of input and 
output capabilities (more formally, we add the axioms \T <t T and oT <t T). 

ff\ presents a type inference algorithm for (an enrichment of) i/o-types, where such a capability t is 
added to the system of lITTl (the notations are different, but we adapt them to our setting for the sake of 
readability). The use of t can be illustrated on the following example process: 

Qi =^ a{t).b{u).{ \t{z).u{z) I c{t) I c{u) ) . 

To typecheck Qi, we can see that the input (resp. output) capability on t (resp. u) needs to be received on 
a (resp. b), which suggests the types a : \\T ,b : \oT . Since t and u are emitted on the same channel c, and 
because of contravariance of output, we compute a supertype of \T and oT, and assign type o\T to c. 

Operationally, the meaning of t is "no i/o-capability at all" (note that this does not prevent from 
comparing names, which may be useful to study behavioural equivalences [6]): in the typing we just 
described, since we only have the input capability on t and the output capability on u, we must renounce 
to all capabilities, and t and u are sent without the receiver to be able to do anything with the name 
except passing it along. Observe also that depending on how the context uses c, a different typing can be 
introduced. For instance, Q\ can be typed by setting a : \'i^T,b : \oT,c : ooT. This typing means that the 
output capability on u is received, used, and transmitted on c, and both capabilities on t are. received, the 
input capability being used locally, while the output capability is transmitted on c. 

The first typing, which involves t, is the one that is computed by the procedure of [7']. It is "minimal", 
in the terminology of [7]. Depending on the situations, a typing like the second one (or the symmetrical 
case, where the input capability is transmitted on c) might be preferable. 

If we take levels into account, and try and typecheck Q\ (which contains a replicated subterm), the 
typings mentioned above can be adapted as follows: we can set a : \^]\^T,b : i°o*'r,c : o^o^r, in which 
case subtyping on levels is used to deduce u : o^T in order to typecheck c{u). Symmetrically, we can 
also set a:\^\^T,b : \^fT,c : o^\^T , and typecheck c{t) using subsumption to deduce t : \^T . 

It is not clear to us how levels should be handled in relation with the f capability. One could think 
that since f prevents any capability to be used on a name, levels have no use, and one could simply adopt 
the subtyping axioms i^r <t T and o^r <t T. This would indeed allow us to typecheck Qi. 

Further investigations on a system for i/o-types with t and levels is left for future work, as well as 
the study of inference for such a system. 

5 Concluding Remarks 

In this paper, we have demonstrated how Pierce and Sangiorgi's i/o-types can be exploited to refine 
the analysis of the simplest of type systems for termination of processes presented in [5]. Other, more 
complex systems are presented in that work, and it would be interesting to study whether they would 
benefit from the enrichment with capabilities and subtyping. One could also probably refine the system 
of Section |2] by distinguishing between linear and replicated input capabilities, as only the latter must 
be controlled for termination (if a name is used in linear input only, its level is irrelevant). 

The question of type inference for our type systems (differently from existing proposals, these are 
presented a la Curry, which is better suited for the study of type inference) can be studied further. It would 
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be interesting to analyse how the procedure of Section 4. 1 could be ported to programming languages 
that obey the discipline of Ln for communication, like Erlang or JoCaml. For the moment, we only 
have preliminary results for a type inference procedure for the system of Section [2] and we would like to 



explore this further. Type inference for the system of Section 3.3 is a challenging question, essentially 
because making the distinction between functional and imperative names belongs to the inference process 
(contrarily to the setting of H, where the syntax of processes contains this information). 
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